The explosive growth of data communication networks, particularly the Internet, presents tremendous opportunities and tremendous challenges for service providers. One such challenge involves keeping up with the demand for bandwidth created by new users, new technologies, and new high-bandwidth applications. For example, a media on demand service provider often transmits bandwidth demanding multi-media content, such as video, to a requesting client or end user.
Due to the dynamically changing nature of traffic carried on networks, service providers need the capability to flexibly, scalably, and cost-effectively allocate network resources to provide required bandwidth. Currently, to address these dynamically changing bandwidth requirements, service providers have little choice but to engineer their networks for “worst-case” traffic volumes, which allows them to meet service commitments but results in under-utilized network resources. Furthermore, when traffic patterns change to an extent that requires reconfiguration of their networks, service providers must manually engineer and provision new connections at both the logical (packet) and physical and/or optical layers of the network, which can be an expensive, complex, and time-consuming task.
An incoming request to a multi-media service provider typically includes very little content as compared to the response which can include a large amount of content. For example, when requesting a movie in a content delivery network, the request for the content itself has very little data whereas the delivery of the movie may involve gigabytes of data. Thus, there is a bandwidth mismatch where communicating the request to the service provider over the network requires minimal bandwidth, but sending the response with the requested content may require significant bandwidth. Local Area Networks (LAN's), Metropolitan Area Networks (MAN's), and Wide Area Networks (WAN's) along with routing devices and network switches (such as IP routers, Frame Relay switches and Asynchronous Transfer Mode switches) interconnected over a Transport Network (such as SONET or G.709) are often used to manage such requests and responses between multiple end users and the service provider. These devices can be implemented by various types of switches and/or network devices including, but not limited to asynchronous transfer mode (ATM) switches, frame relay switches, and internet protocol (IP) switches. Unfortunately, due to bandwidth limitations of conventional network devices and the disproportional bandwidth requirement between requests and responses, such network devices often reach their bandwidth capacity before responding to all requests and, thus, end users can experience significant latency delays when requesting content, while at the same time leaving significant bandwidth idle and unused.
Service providers have used Dense Wavelength Division Multiplexing (DWDM) technology to facilitate the transmission large amounts of content. DWDM is a technology that increases the capacity of an optical fiber by first assigning incoming optical signals to specific wavelengths of light (colors) within a designated band and then combining or multiplexing multiple optical signals so that they can be amplified as a group and transmitted over a single fiber or pair of fibers to increase capacity. Each optical signal can be transmitted at a different rate and in a different format. DWDM applications include ultra-high bandwidth long haul as well as ultra-high-bandwidth metropolitan or inner city-networks, and access networks that are closer to the end user such as SONET, Internet protocol (IP), and asynchronous transfer mode (ATM) networks.
Conventional DWDM systems use a fixed channel plan that may include, for example, 40 separate wavelengths (e.g., from 1528 nm to 1560 nm; a 40 channel systems uses 100 GHz spaced where an 80 channel system may use 50 GHz). Typically, optical signals can be sent across the fiber in the direction from a network A to a network B or from network B to network A. Network devices may receive inputs from all directions, but if the end destination is in common for all those inputs, then there can be a buffer fill and overload creating a data bottleneck where data must stream out a fixed capacity, bi-directional transport port. Thus, a “pipe” may be fully utilizing the A to B direction, while the B to A direction is nearly empty.
It is with these issues in mind, among others, that various aspects of the present disclosure were developed.